client: don't disable TLSv1, TLSv1.1 by default that breaks VMware env#3238
client: don't disable TLSv1, TLSv1.1 by default that breaks VMware env#3238borisstoyanov merged 1 commit intoapache:4.11from
Conversation
This fixes the issue that TLSv1 and TLSv1.1 are still used by CloudStack management server to communicate with VMware vCenter server. With the current defaults, the setup/deployment on VMware fails. Users/admins can however setup the security file according to their env needs to disable TLSv1 and TLSv1.1 for server sockets (8250/agent service for example). Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
yadvr
requested review from
DaanHoogland,
GabrielBrascher,
PaulAngus,
borisstoyanov and
wido
|
Without this fix, by default the env deployment fails for older versions of VMware such as 5.5 and 6.0 (less than up3). |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
borisstoyanov
left a comment
borisstoyanov
left a comment
There was a problem hiding this comment.
LGTM, let's trigger vmware tests on this one
|
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-2648 |
|
@blueorangutan test centos7 vmware-55u3 |
|
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been kicked to run smoke tests |
|
Trillian test result (tid-3446)
|
DaanHoogland
left a comment
DaanHoogland
left a comment
There was a problem hiding this comment.
lgtm, block dev. let's think of additional procedure for production sites
4 participants
This fixes the issue that TLSv1 and TLSv1.1 are still used by CloudStack
management server to communicate with VMware vCenter server. With the
current defaults, the setup/deployment on VMware fails. Users/admins
can however setup the security file according to their env needs to
disable TLSv1 and TLSv1.1 for server sockets (8250/agent service for
example).
Types of changes